Can one of the admins verify this patch?

Runtime changes detected. pull request created. CI running:

I like it, but I'd like Jianghao to take a look as well.

Looking good! It's cool that everyone gets the functionality for free.
Just one question, is there a scenario where something creatable is not batch creatable? In other words, can we merge SupportsBatchCreating into SupportsCreating?

Thanks jianghao, yes there is one scenario where a collection that exposes define(string name) cannot expose Create(Creatable<T>... creatables), the dependency graph requires all creatable resources are of type Resource. The Deployment is not a Resource. This is why we bound generic parameter of SupportsBatchCreation to Resource

public interface SupportsBatchCreation<ResourceT extends Resource> {
...
}

@martinsawicki
Can you share the user scenario behind this feature? I was trying to understand the goal of this PR and that can't really go far without knowing the user scenario. Thanks!

Also, one potential problem is for the async method. For sync methods, we have no problem calling:

List<VirtualMachine> vms = virtualMachines.create(vm1, vm2);

For async, this doesn't compile:

ServiceCall<List<VirtualMachine>> vmsFuture = virtualMachines.createAsync(vm1, vm2, null); // BTW, let's consistently keep callback as the last param since it's optional
/* do a bunch of stuff here */
List<VirtualMachine> vms = vmsFuture.get();

The async issue seems more general [i.e. storing the return value of async with return type ServiceCall<Derived> to a variable of type ServiceCall<Base> ]. For example if we use SDK like below, it compiles.

  ServiceCall<List<VirtualNetworkInner>> list = this.innerCollection.listAllAsync(null);

but not the below code, though List inherits from Collection

  ServiceCall<Collection<VirtualNetworkInner>> list1 = this.innerCollection.listAllAsync(null);

[Below code compiles]

  ServiceCall<VirtualNetworkInner> v = this.innerCollection.getAsync(null, null, null);

[below one not ]

  ServiceCall<com.microsoft.azure.Resource> v1 = this.innerCollection.getAsync(null, null, null);

VirtualNetworkInner inherits com.microsoft.azure.Resource

@jianghaolu as far as the scenario question goes, the main thing I see with this is that I don't have to worry about asynch programming patterns to be able to take advantage of parallelism in the creation of independent resources. Our own automation test cases are a simple case of that --- to test aspects of an LB, a bunch of resources should already exist: VMs, PIPs, VNets. SO the test should pre-create them, but doing it all synchronously is very slow.

Exposing this on a collection of specific resources is a step toward the even more flexible scenario I think we could fairly easily enable as well -- of accepting a list of arbitrary Creatables from the user (via e.g. Azure#create(...)) and have the SDK parallelize it as needed. Since we already have that logic done internally, this should also be relatively simple to expose to users.

Ultimately, I can easily envision users pursuing a pattern (in such more complex multi-resource situations) of not calling individual <Resource>.create() at all, but only dealing with Creatables and passing them all to a single .create() at the end (or .createAsynch()).

This could perhaps marry the best of both worlds - the intuitiveness, familiarity and debuggability of the imperative synchronous programming model with the performance of the declarative and asynchronous ARM template model.
(It also has more of that Promise-like feel to it, where asynch operations are still ordered based on their dependency trees and failures can be handled in one place)

Just my thoughts on that.